![[Amazon FSx for NetApp ONTAP] NetApp BlueXPを使ってFlexCacheボリュームを作ってみた](https://devio2023-media.developers.io/wp-content/uploads/2023/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] NetApp BlueXPを使ってFlexCacheボリュームを作ってみた
2024.06.28簡単にFlexClacheの設定をしたいな
こんにちは、のんピ(@non____97)です。
皆さんは簡単にFlexClacheの設定をしたいなと思ったことはありますか? 私はあります。
FlexClacheとは異なるONTAPクラスター、SVM上のボリュームのデータをキャッシュする機能です。FlexClacheの詳細は以下記事をご覧ください。
Amazon FSx for NetApp ONTAP(以降FSxN)において、FlexClacheの設定をするには以下の手順を踏む必要があります。
- クラスタピアリング(異なるFSxNファイルシステム間でFlexClacheを用意したい場合)
- SVMピアリング(異なるSVM間でFlexClacheを用意したい場合)
- FlexClacheボリュームの作成
個人的にはSSHの接続先を右往左往することになるためピアリングの設定が地味に面倒に感じます。
そんなお悩みはNetApp BlueXP(以降BlueXP)を使用することで解消できます。
BlueXPとはオンプレとクラウドのストレージやNetApp製品を統合管理するSaaSです。詳細は以下記事をご覧ください。
実際にBlueXPを使ってFlexCacheを設定してみました。
やってみた
検証環境
検証環境は以下のとおりです。
![[Amazon FSx for NetApp ONTAP]NetApp BlueXPを使ってFlexCacheボリュームを作ってみた](https://devio2023-media.developers.io/wp-content/uploads/2024/06/7416b73c65e8436b5a6a91ecc4040d3d.png)
東京リージョンとバージニア北部リージョンにFSxNファイルシステムを用意し、東京リージョンのFSxNボリュームのキャッシュをバージニア北部リージョンのFSxNボリュームに持たせます。
VPC、FSxN、BlueXP、BlueXP Connector周りのセットアップは完了しています。
BlueXP周りのセットアップは以下記事をご覧ください。
セットアップ完了後の状態は以下のとおりです。
表示されているFSxNはそれぞれ以下のリージョンで動作しています。
- helixcore_fs_apne1 : 東京リージョン
- helixcore_fs_use1 : バージニア北部リージョン
FlexCacheの設定
FlexCacheの設定を行います。
helixcore_fs_apne1をドラッグして、helixcore_fs_use1に重ねます。すると、Enable this serviceと表示されるのでVolume cachingをクリックします。
FlexCacheの設定をします。helixcore_fs_apne1上のボリュームvol1_apne1を選択します。その他はデフォルトでCreate cachesをクリックします。
Your caches are being created. Track the progress on timeline page.と表示されました。timelineのリンクをクリックして作成状況を確認しましょう。
確認したタイミングで、FlexCacheの設定が完了していました。FlexCacheの設定だけでなく、クラスタピアリングやSVMピアリングもしてくれるのは非常に楽でありがたいです。
先の画面に戻ると、FlexCacheの設定が表示されていました。
詳細は以下のとおりです。
作成されたFlexCacheボリュームをAdvanced Viewで確認しましょう。キャッシュのボリュームなのでキャッシュミスのメトリクスがありますね。また、オリジンボリュームの情報やFlexCacheボリュームのコンスティチュエントボリュームの情報も確認できます。
ちなみに、オリジンボリュームの詳細は以下のとおりです。
Canvasに戻ると、helixcore_fs_apne1のキャッシュがhelixcore_fs_use1に作成されていることが表現されていました。
キャッシュボリュームの読み取り速度確認 (1回目)
キャッシュボリュームの読み取り速度を確認します。
バージニア北部リージョンのEC2インスタンスからFlexCacheボリュームとオリジンボリュームをマウントします。なお、異なるFSxNのエンドポイント名はFSxNが存在するVPC外から名前解決することはできないので、IPアドレスを直接指定します。
$ sudo mkdir -p /mnt/fsxn/vol1_apne1
$ sudo mkdir -p /mnt/fsxn/vol1_apne1_cache
$ dig svm-0929b73b0d5198e37.fs-02486ab43fc5902c8.fsx.ap-northeast-1.amazonaws.com
; <<>> DiG 9.16.48-RH <<>> svm-0929b73b0d5198e37.fs-02486ab43fc5902c8.fsx.ap-northeast-1.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22988
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;svm-0929b73b0d5198e37.fs-02486ab43fc5902c8.fsx.ap-northeast-1.amazonaws.com. IN A
;; AUTHORITY SECTION:
fsx.ap-northeast-1.amazonaws.com. 142 IN SOA ns-1031.awsdns-00.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 0 msec
;; SERVER: 10.20.0.2#53(10.20.0.2)
;; WHEN: Thu Jun 27 06:32:32 UTC 2024
;; MSG SIZE rcvd: 186
$ sudo mount -t nfs 10.10.134.143:/vol1_apne1 /mnt/fsxn/vol1_apne1
$ sudo mount -t nfs svm-0bed7a19e83f8e6c5.fs-09b61052262da98b8.fsx.us-east-1.amazonaws.com:/vol1_apne1_cache /mnt/fsxn/vol1_apne1_cache
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
10.10.134.143:/vol1_apne1 nfs4 973G 113G 861G 12% /mnt/fsxn/vol1_apne1
svm-0bed7a19e83f8e6c5.fs-09b61052262da98b8.fsx.us-east-1.amazonaws.com:/vol1_apne1_cache nfs4 973G 113G 861G 12% /mnt/fsxn/vol1_apne1_cache
オリジンボリュームに書き込みます。
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol1_apne1/test-file-1 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 48.6819 s, 22.1 MB/s
$ ls -l /mnt/fsxn/vol1_apne1
total 1052712
-rw-r--r--. 1 nobody nobody 1073741824 Jun 27 06:39 test-file-1
$ ls -l /mnt/fsxn/vol1_apne1_cache/
total 1052712
-rw-r--r--. 1 root root 1073741824 Jun 27 06:39 test-file-1
レイテンシーが高いのか速度はあまり出ていないですね。経験上、同スペックで同一リージョンの場合200〜600MBpsほど出ます。
参考までにNetwork Managerで東京リージョンとバージニア北部リージョン間のレイテンシーを確認すると145-155msほどでした。
それではFlexCacheボリュームの読み込みをしまししょう。
$ dd if=/mnt/fsxn/vol1_apne1_cache/test-file-1 of=/dev/null bs=1M iflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 341.943 s, 3.1 MB/s
3.1MBpsと非常に遅いです。
BlueXPで読み込み実行中のFlexCacheボリュームのメトリクスを確認します。
キャッシュミスが100%であり、全てのデータをオリジンに取りに行っていることが分かりますね。なお、メトリクスは2-5秒間隔でリフレッシュされて、最新の値をほぼリアルタイムで確認できました。FSxNにおけるCloudWatchメトリクスの場合は最小1分間隔なので非常に高解像度で状況を把握できるのはありがたいです。
読み取り完了後のメトリクスの状態は以下のとおりです。全体的に低調です。
キャッシュボリュームの読み取り速度確認 (2回目)
それでは、2回目の読み取りです。
$ dd if=/mnt/fsxn/vol1_apne1_cache/test-file-1 of=/dev/null bs=1M iflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.69277 s, 634 MB/s
634MBpsと爆速です。
BlueXPでFlexCacheボリュームのメトリクスを確認します。
対象時間にはキャッシュミスは発生しておらず、一瞬IOが発生したことが分かります。FSxNファイルシステムhelixcore_fs_use1のノード側でキャッシュを保持しているとも思いますが、キャッシングのメリットを感じます。
FlexCacheボリュームに書き込んだファイルの読み込み
FlexCacheボリュームに書き込んだファイルの読み込みはどうでしょうか。
まず、FlexCacheボリュームに書き込みを行います。
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol1_apne1_cache/test-file-2 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 79.8644 s, 13.4 MB/s
13.4MBpsと遅いですね。経験上、同スペックで同一リージョンの場合140〜150MBpsほど出ます。
東京リージョンにEC2インスタンスを立てて、FSxNファイルシステムhelixcore_fs_apne1のボリュームに書き込むと141MBps出ました。
$ sudo mkdir -p /mnt/fsxn/vol1_apne1
$ sudo mount -t nfs 10.10.134.143:/vol1_apne1 /mnt/fsxn/vol1_apne1
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol1_apne1/test-file-4 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.5938 s, 141 MB/s
FlexCacheボリュームへの書き込みが遅い原因はオリジンボリュームからACKが返ってから次の書き込みを行なっているためと考えます。
こちらのFSxNファイルシステムのONTAPのバージョンは9.13.1です。
FsxId09b61052262da98b8::> version
NetApp Release 9.13.1P9: Fri Apr 19 17:13:02 UTC 2024
そのため、ONTAP 9.15.1でGAされたFlexCacheのWritebackはサポートされておらず、Writethroughで動作しています。ACKが返ってくるまで書き込みが終了しないので同期書き込みだとパフォーマンスがでなさそうですね。
BlueXPでFlexCacheボリュームのメトリクスを確認します。
15:55ごろが書き込みをした時刻ですが、レイテンシーがグッと増加しています。IOPSやスループットも元気がありませんね。
それでは読み込みをします。
$ dd if=/mnt/fsxn/vol1_apne1_cache/test-file-2 of=/dev/null bs=1M iflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 291.189 s, 3.7 MB/s
3.7MBpsと非常に低速です。FlexCacheボリュームに書き込んだデータであるためパフォーマンスは改善されるかと想像していたのではすが、そういう訳ではないようです。
BlueXPでFlexCacheボリュームのメトリクスを確認します。
-
読み込み実行中
-
読み込み完了後
キャッシュミスしているということは、FlexCacheボリューム上にデータブロックが存在しないと判定されてしまっているようです。
再読み込みを行います。
$ dd if=/mnt/fsxn/vol1_apne1_cache/test-file-2 of=/dev/null bs=1M iflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.68927 s, 636 MB/s
636MBpsと爆速です。
BlueXPで確認したFlexCacheボリュームのメトリクスは以下のとおりです。
読み取り時にキャッシュミスが発生していないことが分かります。
GUIで簡単にFlexCacheの設定や管理を行いたい方に
NetApp BlueXPを使ってFlexCacheボリュームを作ってみました
GUIで簡単にFlexCacheの設定や管理を行いたい方には非常にありがたい機能ですね。個人的にはメトリクスの粒度が数秒であるのがとても助かります。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Amazon FSx for NetApp ONTAP] SMBでファイルオープン中にフェイルオーバーが発生した場合の挙動を確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
